feat(membership): add inactive member detection#1061
feat(membership): add inactive member detection#1061avivkeller wants to merge 2 commits intonodejs:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Adds an automated “inactive member” monitor for the org by running a scheduled GitHub Actions workflow that scans org membership/team data and posts (or updates) a report issue in this repository.
Changes:
- Added a new Node.js script to fetch org members/teams, check recent activity, and render a Markdown report.
- Added a daily scheduled GitHub Actions workflow to run the script using a user token.
- Updated the access-token registry documentation to include the new secret entry.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 10 comments.
| File | Description |
|---|---|
tools/get-inactive-members.mjs |
Implements org member/team fetch, activity classification, report rendering, and issue upsert logic. |
.github/workflows/get-inactive-members.yml |
Schedules and runs the new script via actions/github-script using GH_USER_TOKEN. |
request-an-access-token.md |
Documents the new GH_USER_TOKEN usage/registry entry for nodejs/admin. |
Comments suppressed due to low confidence (1)
tools/get-inactive-members.mjs:513
- The report issue is only created/updated when
inactive.length > 0. This means (1) the rendered “No inactive members found” state is never posted, and (2) an existing report issue won’t be updated if the org becomes fully active—leaving stale results in the issue body. Upsert the issue unconditionally so the report always reflects the latest scan.
core.info(`Report available at: ${html_url}`);
}
}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Thanks Aviv! I was gonna write out the details tomorrow with a couple options. Are you familiar with the consensus reached? |
I am not, I've been away, can you summarize? |
|
Yeah, I shall do tomorrow 🙂 |
|
I think the "no activity" criteria should be adjusted:
The rest is a wishlist. What is here now is a good With the new team-based setup for Core, that will need some special handling because there are 1–2 repos that need to be checked ( It would ideally also check meeting minutes for attendees; facilitating that check may require meeting minutes to adhere to a partially prescribed/standard format, and them to be stored in a standard place (eg For the report, it would ideally break down to which team(s) the member is inactive, as well as call out when the member is completely inactive across the whole org. The reports would ideally also specify how long each member has been inactive (in a human-friendly way, like I think it would be good to open:
|
avivkeller
force-pushed
the
get-inactive-members
branch
from
2a2fbfc to
43bc15c
Compare
|
@JakobJingleheimer Right now, I have it stored at https://github.com/avivkeller/organization-auditor/ due to the complexity, but it: Considers a user as organization-inactive if they haven't committed to a single repository in 3 months |
|
We'll need to add a "team map" to this repository first, so it knows where to open the issue for individual team inactivity, i.e. |
|
Sweet, thanks! Looks pretty good :) A couple questions:
I wonder if there's a more dynamic way to handle this 🤔 What if team repos and team names always matched? Would the web team (and others) mind if their name was changed from Multiple sources of truth is perhaps also a small concern: |
Well, right now, it generates a report once a week, doesn't it make sense to re-use the old issue? Why would we need to create a new one?
As you said, that's tricky, since, for instance, If you didn't want to hardcode this, I think the other options are:
|
Ooooh, I was thinking it would do it less frequently. Yes, that would get ruul annoying.
Mmm, that's the sort of thing I was thinking to rename (and whether those teams would mind).
I think either or both of those would be good in general, so if that work solves this problem, two-fer. Isn't that backwards though—wouldn't you need to start with the team and then check its repository? (nodejs has a lotta repos—hundreds—but only a couple handfuls are team repos, so if you go the other way, it's a rather large haystack). |
If we go with option A (link to the repo in each team's description), it should be pretty easy, and not require much overhead, since we already fetch the teams. Option B wouldn't require too much overhead, since we can Can @nodejs/TSC update each team with an associated repo to include the repo link their description, maybe |
@JakobJingleheimer mentioned that during the collaborator's summit, it was discussed that we should be more wary of the size of the organization. This adds a daily workflow to keep a constant "activity monitor" issue open.
It requires that a
public_repo,read:orgtoken be made for this repository.An example issue that this workflow generates is below (Note: In a real issue, these users would be pinged):
Workflow Output